<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
<title>The Collection Tree Protocol (CTP)</title>
<meta name="author" content="Rodrigo Fonseca, Omprakash Gnawali, Kyle Jamieson, Sukun Kim, Philip Levis, and Alec Woo" />
<style type="text/css">

/*
:Author: David Goodger
:Contact: goodger@users.sourceforge.net
:date: $Date: 2009-02-03 23:07:32 $
:version: $Revision: 1.11 $
:copyright: This stylesheet has been placed in the public domain.

Default cascading style sheet for the HTML output of Docutils.
*/
body {
  font-family: Times;
  font-size: 16px;
}

.first {
  margin-top: 0 ! important }

.last {
  margin-bottom: 0 ! important }

.hidden {
  display: none }

a.toc-backref {
  text-decoration: none ;
  color: black }

blockquote.epigraph {
  margin: 2em 5em ; }

dd {
  margin-bottom: 0.5em }

div.abstract {
  margin: 2em 5em }

div.abstract p.topic-title {
  font-weight: bold ;
  text-align: center }

div.attention, div.caution, div.danger, div.error, div.hint,
div.important, div.note, div.tip, div.warning, div.admonition {
  margin: 2em ;
  border: medium outset ;
  padding: 1em }

div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title {
  color: red ;
  font-weight: bold ;
  font-family: sans-serif }

div.hint p.admonition-title, div.important p.admonition-title,
div.note p.admonition-title, div.tip p.admonition-title,
div.admonition p.admonition-title {
  font-weight: bold ;
  font-family: sans-serif }

div.dedication {
  margin: 2em 5em ;
  text-align: center ;
  font-style: italic }

div.dedication p.topic-title {
  font-weight: bold ;
  font-style: normal }

div.figure {
  margin-left: 2em }

div.footer, div.header {
  font-size: smaller }

div.line-block {
  display: block ;
  margin-top: 1em ;
  margin-bottom: 1em }

div.line-block div.line-block {
  margin-top: 0 ;
  margin-bottom: 0 ;
  margin-left: 1.5em }

div.sidebar {
  margin-left: 1em ;
  border: medium outset ;
  padding: 0em 1em ;
  background-color: #ffffee ;
  width: 40% ;
  float: right ;
  clear: right }

div.sidebar p.rubric {
  font-family: sans-serif ;
  font-size: medium }

div.system-messages {
  margin: 5em }

div.system-messages h1 {
  color: red }

div.system-message {
  border: medium outset ;
  padding: 1em }

div.system-message p.system-message-title {
  color: red ;
  font-weight: bold }

div.topic {
  margin: 2em }

h1 {
  font-family: Arial, sans-serif;
  font-size: 20px;
}

h1.title {
 text-align: center;
 font-size: 32px;
}

h2 {
 font-size: 16px;
 font-family: Arial, sans-serif;
}

h2.subtitle {
  text-align: center }

h3 {
 font-size: 12px;
 font-family: Arial, sans-serif;
}

hr {
  width: 75% }

ol.simple, ul.simple {
  margin-bottom: 1em }

ol.arabic {
  list-style: decimal }

ol.loweralpha {
  list-style: lower-alpha }

ol.upperalpha {
  list-style: upper-alpha }

ol.lowerroman {
  list-style: lower-roman }

ol.upperroman {
  list-style: upper-roman }

p.attribution {
  text-align: right ;
  margin-left: 50% }

p.caption {
  font-style: italic }

p.credits {
  font-style: italic ;
  font-size: smaller }

p.label {
  white-space: nowrap }

p.rubric {
  font-weight: bold ;
  font-size: larger ;
  color: maroon ;
  text-align: center }

p.sidebar-title {
  font-family: sans-serif ;
  font-weight: bold ;
  font-size: larger }

p.sidebar-subtitle {
  font-family: sans-serif ;
  font-weight: bold }

p.topic-title {
  font-weight: bold }

pre.address {
  margin-bottom: 0 ;
  margin-top: 0 ;
  font-family: serif ;
  font-size: 100% }

pre.line-block {
  font-family: serif ;
  font-size: 100% }

pre.literal-block, pre.doctest-block {
  margin-left: 2em ;
  margin-right: 2em ;
  background-color: #eeeeee;
  border-color: #000000;
  border-width: thin; 
  font-size: 14px
}

span.classifier {
  font-family: sans-serif ;
  font-style: oblique }

span.classifier-delimiter {
  font-family: sans-serif ;
  font-weight: bold }

span.interpreted {
  font-family: sans-serif }

span.option {
  white-space: nowrap }

span.option-argument {
  font-style: italic }

span.pre {
  white-space: pre }

span.problematic {
  color: red }

table {
  margin-top: 0.5em ;
  margin-bottom: 0.5em }

table.citation {
  border-left: solid thin gray ;
  padding-left: 0.5ex }

table.docinfo {
  margin: 2em 4em;
}

table.footnote {
  border-left: solid thin black ;
  padding-left: 0.5ex }

td, th {
  padding-left: 0.5em ;
  padding-right: 0.5em ;
  vertical-align: top }

th.docinfo-name, th.field-name {
  font-weight: bold ;
  text-align: left ;
  white-space: nowrap;
  }

h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
  font-size: 100% }

tt {}

ul.auto-toc {
  list-style-type: none }

</style>
</head>
<body>
<div class="document" id="the-collection-tree-protocol-ctp">
<h1 class="title">The Collection Tree Protocol (CTP)</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr class="field"><th class="docinfo-name">TEP:</th><td class="field-body">123</td>
</tr>
<tr class="field"><th class="docinfo-name">Group:</th><td class="field-body">Network Working Group</td>
</tr>
<tr class="field"><th class="docinfo-name">Type:</th><td class="field-body">Documentary</td>
</tr>
<tr><th class="docinfo-name">Status:</th>
<td>Final</td></tr>
<tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">&gt; 2.1</td>
</tr>
<tr><th class="docinfo-name">Author:</th>
<td>Rodrigo Fonseca, Omprakash Gnawali, Kyle Jamieson, Sukun Kim, Philip Levis, and Alec Woo</td></tr>
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">3-Aug-2006</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.15</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2009-01-16</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List &lt;tinyos-devel at mail.millennium.berkeley.edu&gt;</td>
</tr>
</tbody>
</table>
<div class="note">
<p class="first admonition-title">Note</p>
<p class="last">This memo documents a part of TinyOS for the TinyOS Community, and
requests discussion and suggestions for improvements.  Distribution
of this memo is unlimited. This memo is in full compliance with
TEP 1.</p>
</div>
<div class="section">
<h1><a id="abstract" name="abstract">Abstract</a></h1>
<p>This memo documents the Collection Tree Protocol (CTP), which
provides best-effort anycast datagram communication to one of the
collection roots in a network.</p>
</div>
<div class="section">
<h1><a id="introduction" name="introduction">1. Introduction</a></h1>
<p>A collection protocol delivers data to one of possibly several data
sinks, providing a many-to-one network layer. Collection is a
fundamental component of most sensor network applications. The
Collection Tree Protocol (CTP) is a reference Collection protocol in
TinyOS 2.x. The users use Collection interfaces described in TEP 119
<a class="footnote-reference" href="#id8" id="id1" name="id1">[3]</a> to use CTP in their applications.</p>
<p>In this TEP, after a brief discussion of Collection and CTP, we
specify the CTP routing and data frames. CTP uses routing frames to
update and build collection tree in the network. CTP uses data frames
to deliver application payload to the sink and to probe topology
inconsistencies.</p>
<p>All fields in this specification are in network byte order.</p>
</div>
<div class="section">
<h1><a id="assumptions-and-limitations" name="assumptions-and-limitations">2. Assumptions and Limitations</a></h1>
<p>CTP is a tree-based collection protocol. Some number of nodes in a
network advertise themselves as tree roots. Nodes form a set of routing
trees to these roots. CTP is <strong>address-free</strong> in that a node does not
send a packet to a particular root; instead, it implicitly chooses a
root by choosing a next hop. Nodes generate routes to roots using
a routing gradient.</p>
<p>The CTP protocol assumes that the data link layer provides four things:</p>
<blockquote>
<ol class="arabic simple">
<li>Provides an efficient local broadcast address.</li>
<li>Provides synchronous acknowledgments for unicast packets.</li>
<li>Provides a protocol dispatch field to support multiple higher-level
protocols.</li>
<li>Has single-hop 16-bit source and destination fields.</li>
</ol>
</blockquote>
<p>CTP assumes that it has link quality estimates of some number of nearby
neighbors. These provide an estimate of the number of transmissions it
takes for the node to send a unicast packet whose acknowledgment is
successfully received.</p>
<p>CTP has several mechanisms in order to achieve high delivery
reliability, but it does not promise 100% reliable delivery. It is a
best effort protocol.</p>
<p>CTP is designed for relatively low traffic rates such that there is
enough space in the channel to transmit and receive routing frames
even when the network is forwarding collection data
frames. Bandwidth-limited systems or high data rate applications might
benefit from a different protocol, which can, for example, pack
multiple small frames into a single data-link packet or employ rate
control mechanisms.</p>
</div>
<div class="section">
<h1><a id="collection-and-ctp" name="collection-and-ctp">3. Collection and CTP</a></h1>
<p>CTP uses expected transmissions (ETX) as its routing gradient. A root
has an ETX of 0.  The ETX of a node is the ETX of its parent plus the
ETX of its link to its parent. This additive measure assumes that
nodes use link-level retransmissions.  Given a choice of valid routes,
CTP SHOULD choose the one with the lowest ETX value. CTP represents
ETX values as 16-bit decimal fixed-point real numbers with a precision
of tenths. An ETX value of 45, for example, represents an ETX of 4.5,
while an ETX value of 10 represents an ETX of 1.</p>
<p>Routing loops are a problem that can emerge in a CTP network. Routing
loops generally occur when a node choose a new route that has a
significantly higher ETX than its old one, perhaps in response to
losing connectivity with a candidate parent. If the new route includes
a node which was a descendant, then a loop occurs.</p>
<p>CTP addresses loops through two mechanisms. First, every CTP packet
contains a node's current gradient value. If CTP receives a data frame with
a gradient value lower than its own, then this indicates that there
is an inconsistency in the tree. CTP tries to resolve the inconsistency
by broadcasting a beacon frame, with the hope that the node which sent
the data frame will hear it and adjust its routes accordingly. If a
collection of nodes is separated from the rest of the network, then they
will form a loop whose ETX increases forever. CTP's second mechanism
is to not consider routes with an ETX higher than a reasonable constant.
The value of this constant is implementation dependent.</p>
<p>Packet duplication is an additional problem that can occur in CTP.
Packet duplication occurs when a node receives a data frame
successfully and transmits an ACK, but the ACK is not received. The
sender retransmits the packet, and the receiver receives it a second
time. This can have disasterous effects over multiple hops, as the
duplication is exponential.  For example, if each hop on average
produces one duplicate, then on the first hop there will be two
packets, on the second there will be four, on the third there will be
eight, etc. CTP keeps a small cache of packet signature for the
packets it has seen to detect packet duplicates. When a new packet
arrives, if its signature results in cache hit, CTP drops the packet
because it is a duplicate.</p>
<p>Routing loops complicate duplicate suppression, as a routing loop may
cause a node to legitimately receive a packet more than once. Therefore,
if a node suppresses duplicates based solely on originating address and
sequence number, packets in routing loops may be dropped. CTP data frames
therefore have an additional time has lived (THL) field, which the
routing layer increments on each hop. A link-level retransmission has
the same THL value, while a looped version of the packet is unlikely
to do so.</p>
</div>
<div class="section">
<h1><a id="ctp-data-frame" name="ctp-data-frame">4. CTP Data Frame</a></h1>
<p>The CTP data frame format is as follows:</p>
<pre class="literal-block">
                     1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|C| reserved  |      THL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              ETX              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             origin            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     seqno     |   collect_id  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
<p>Field definitions are as follows:</p>
<blockquote>
<ul class="simple">
<li>P: Routing pull. The P bit allows nodes to request routing information from other nodes. If the unicast destination of the data frame with a valid route hears a packet with the P bit set, it SHOULD transmit a routing frame in the near future. Nodes other than the link-layer destination of the data frame MAY respond to the P bit in the data frame.</li>
<li>C: Congestion notification. If a node drops a CTP data frame, it MUST set the C field on the next data frame it transmits.</li>
<li>THL: Time Has Lived. When a node generates a CTP data frame, it MUST set THL to 0. When a node receives a CTP data frame, it MUST increment the THL. If a node receives a THL of 255, it increments it to 0.</li>
<li>ETX: The ETX routing metric of the single-hop sender. When a node transmits a CTP data frame, it MUST put the ETX value of its route through the single-hop destination in the ETX field.  If a node receives a packet with a lower gradient than its own, then it MUST schedule a routing frame in the near future.</li>
<li>origin: The originating address of the packet. A node forwarding a data frame MUST NOT modify the origin field.</li>
<li>seqno: Origin sequence number. The originating node sets this field, and a node forwarding a data frame MUST NOT modify it.</li>
<li>collect_id: Higher-level protocol identifier. The origin sets this field, and a node forwarding a data frame MUST NOT modify it.</li>
<li>data: the data payload, of zero or more bytes. A node forwarding a data frame MUST NOT modify the data payload. The length of the data field is computed by subtracting the size of the CTP header from the size of the link layer payload provided by the link layer.</li>
</ul>
</blockquote>
<p>Together, the origin, seqno and collect_id fields denote a unique
<strong>*origin packet.*</strong> Together, the origin, seqno, collect_id, and
THL denote a unique <strong>*packet instance*</strong> within the network. The
distinction is important for duplicate suppression in the presence
of routing loops. If a node suppresses origin packets, then if
asked to forward the same packet twice due to a routing loop, it will
drop the packet. However, if it suppresses packet instances, then it
will route successfully in the presence of transient loops unless the
THL happens to wrap around to a forwarded packet instance.</p>
<p>A node MUST send CTP data frames as unicast messages with link-layer
acknowledgments enabled.</p>
</div>
<div class="section">
<h1><a id="ctp-routing-frame" name="ctp-routing-frame">5. CTP Routing Frame</a></h1>
<p>The CTP routing frame format is as follows:</p>
<pre class="literal-block">
                     1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|C| reserved  |     parent    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     parent    |      ETX      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      ETX      |
+-+-+-+-+-+-+-+-+
</pre>
<p>The fields are as follows:</p>
<blockquote>
<ul class="simple">
<li>P: Same as data frame with one difference: Routing frames are broadcast so multiple nodes respond to the P bit in the routing frame.</li>
<li>C: Congestion notification. If a node drops a CTP data frame, it MUST set the C field on the next routing frame it transmits.</li>
<li>parent: The node's current parent.</li>
<li>metric: The node's current routing metric value.</li>
</ul>
</blockquote>
<p>When a node hears a routing frame, it MUST update its routing table to
reflect the address' new metric. If a node's ETX value changes
significantly, then CTP SHOULD transmit a broadcast frame soon thereafter
to notify other nodes, which might change their routes. The parent
field acts as a surrogate for the single-hop destination field of
a data packet: a parent can detect when a child's ETX is significantly
below its own. When a parent hears a child advertise an ETX below its
own, it MUST schedule a routing frame for transmission in the near
future.</p>
<p>A node MUST send CTP routing frames as broadcast messages.</p>
</div>
<div class="section">
<h1><a id="implementation" name="implementation">6. Implementation</a></h1>
<p>An implementation of CTP can be found in the tos/lib/net/ctp directory
of TinyOS 2.0. This section describes the structure of that implementation
and is not in any way part of the specification of CTP.</p>
<p>This implementation has three major subcomponents:</p>
<p>1) A <strong>link estimator</strong>, which is responsible for estimating the
single-hop ETX of communication with single-hop neighbors.</p>
<p>2) A <strong>routing engine</strong>, which uses link estimates as well as
network-level information to decide which neighbor is the next
routing hop.</p>
<p>3) A <strong>forwarding engine</strong>, which maintains a queue of packets
to send. It decides when and if to send them. The name is a little
misleading: the forwarding engine is responsible for forwarded traffic
as well as traffic generated on the node.</p>
<div class="section">
<h2><a id="link-estimation" name="link-estimation">6.1 Link Estimation</a></h2>
<p>The implementation uses two mechanisms to estimate the quality of a link:
periodic LEEP <a class="footnote-reference" href="#id6" id="id2" name="id2">[1]</a> packets and data packets. The implementation sends
routing beacons as LEEP packets. These packets seed the neighbor table
with bidirectional ETX values. The implementation adapts its beaconing
rate based on network dynamics using an algorithm similar to the
trickle dissemination protocol <a class="footnote-reference" href="#id7" id="id3" name="id3">[2]</a>. Beacons are sent on an exponentially
increasing randomized timer. The implementation resets the timer to a
small value when one or more of the following conditions are met:</p>
<blockquote>
<ol class="arabic simple">
<li>The routing table is empty (this also sets the P bit)</li>
<li>The node's routing ETX increases by &gt;= 1 transmission</li>
<li>The node hears a packet with the P bit set</li>
</ol>
</blockquote>
<p>The implementation augments the LEEP link estimates with data
transmissions. This is a direct measure of ETX. Whenever the data path
transmits a packet, it tells the link estimator the destination and
whether it was successfully acknowledged. The estimator produces an
ETX estimate every 5 such transmissions, where 0 successes has an ETX
of 6.</p>
<p>The estimator combines the beacon and data estimates by incorporating
them into an exponentially weighted moving average. Beacon-based
estimates seed the neighbor table. The expectation is that the low
beacon rate in a stable network means that for a selected route,
data estimates will outweigh beacon estimates. Additionally, as
the rate at which CTP collects data estimates is proportional to
the transmission rate, then it can quickly detect a broken link and
switch to another candidate neighbor.</p>
<p>The component <tt class="docutils literal"><span class="pre">tos/lib/net/4bitle/LinkEstimatorP</span></tt> implements the
link estimator. It couples LEEP-based and data-based estimates as
described in <a class="footnote-reference" href="#id9" id="id4" name="id4">[4]</a>.</p>
</div>
<div class="section">
<h2><a id="routing-engine" name="routing-engine">6.2 Routing Engine</a></h2>
<p>The implementation's routing engine is responsible for picking the next
hop for a data transmission. It keeps track of the path ETX values of
a subset of the nodes maintained by the link estimation table. The minimum
cost route has the smallest sum the path ETX from that node and the link
ETX of that node. The path ETX is therefore the sum of link ETX values
along the entire route. The component <tt class="docutils literal"><span class="pre">tos/lib/net/ctp/CtpRoutingEngineP</span></tt>
implements the routing engine.</p>
</div>
<div class="section">
<h2><a id="forwarding-engine" name="forwarding-engine">6.3 Forwarding Engine</a></h2>
<p>The component <tt class="docutils literal"><span class="pre">tos/lib/net/ctp/CtpForwardingEngineP</span></tt> implements the
forwarding engine. It has five responsibilities:</p>
<blockquote>
<ol class="arabic simple">
<li>Transmitting packets to the next hop, retransmitting when necessary, and
passing acknowledgment based information to the link estimator</li>
<li>Deciding <em>when</em> to transmit packets to the next hop</li>
<li>Detecting routing inconsistencies and informing the routing engine</li>
<li>Maintaining a queue of packets to transmit, which are a mix of locally
generated and forwarded packets</li>
<li>Detecting single-hop transmission duplicates caused by lost acknowledgments</li>
</ol>
</blockquote>
<p>The four key functions of the forwading engine are packet reception
(<tt class="docutils literal"><span class="pre">SubReceive.receive()</span></tt>), packet forwarding (<tt class="docutils literal"><span class="pre">forward()</span></tt>), packet
transmission (<tt class="docutils literal"><span class="pre">sendTask()</span></tt>) and deciding what to do after a packet
transmission (<tt class="docutils literal"><span class="pre">SubSend.sendDone()</span></tt>).</p>
<p>The receive function decides whether or not the node should forward a
packet. It checks for duplicates using a small cache of recently received
packets. If it decides a packet is not a duplicate, it calls the
forwading function.</p>
<p>The forwarding function formats the packet for forwarding. It checks the
received packet to see if there is possibly a loop in the network.
It checks if there is space in the transmission queue.
If there is no space, it drops the packet and sets the C bit. If the
transmission queue was empty, then it posts the send task.</p>
<p>The send task examines the packet at the head of the transmission
queue, formats it for the next hop (requests the route from the
routing layer, etc.), and submits it to the AM layer.</p>
<p>When the send completes, sendDone examines the packet to see the result.
If the packet was acknowledged, it pulls the packet off the transmission
queue. If the packet was locally generated, it signals sendDone() to the
client above. If it was forwarded, it returns the packet to the forwarding
message pool. If there are packets remaining in the queue (e.g., the
packet was not acknowledged), it starts a randomized timer that reposts
this task. This timer essentially rate limits CTP so that it does not
stream packets as quickly as possible, in order to prevent self-collisions
along the path.</p>
</div>
</div>
<div class="section">
<h1><a id="citations" name="citations">7. Citations</a></h1>
<div class="line-block">
<div class="line">Rodrigo Fonseca</div>
<div class="line">473 Soda Hall</div>
<div class="line">Berkeley, CA 94720-1776</div>
<div class="line"><br /></div>
<div class="line">phone - +1 510 642-8919</div>
<div class="line">email - <a class="reference" href="mailto:rfonseca&#64;cs.berkeley.edu">rfonseca&#64;cs.berkeley.edu</a></div>
<div class="line"><br /></div>
<div class="line"><br /></div>
<div class="line">Omprakash Gnawali</div>
<div class="line">Ronald Tutor Hall (RTH) 418</div>
<div class="line">3710 S. McClintock Avenue</div>
<div class="line">Los Angeles, CA 90089</div>
<div class="line"><br /></div>
<div class="line">phone - +1 213 821-5627</div>
<div class="line">email - <a class="reference" href="mailto:gnawali&#64;usc.edu">gnawali&#64;usc.edu</a></div>
<div class="line"><br /></div>
<div class="line"><br /></div>
<div class="line">Kyle Jamieson</div>
<div class="line">The Stata Center</div>
<div class="line">32 Vassar St.</div>
<div class="line">Cambridge, MA 02139</div>
<div class="line"><br /></div>
<div class="line">email - <a class="reference" href="mailto:jamieson&#64;csail.mit.edu">jamieson&#64;csail.mit.edu</a></div>
<div class="line"><br /></div>
<div class="line"><br /></div>
<div class="line">Philip Levis</div>
<div class="line">358 Gates Hall</div>
<div class="line">Computer Science Laboratory</div>
<div class="line">Stanford University</div>
<div class="line">Stanford, CA 94305</div>
<div class="line"><br /></div>
<div class="line">phone - +1 650 725 9046</div>
<div class="line">email - <a class="reference" href="mailto:pal&#64;cs.stanford.edu">pal&#64;cs.stanford.edu</a></div>
<div class="line"><br /></div>
<div class="line"><br /></div>
<div class="line">Alec Woo</div>
<div class="line">Arch Rock Corporation</div>
<div class="line">501 2nd St. Ste 410</div>
<div class="line">San Francisco, CA 94107-4132</div>
<div class="line"><br /></div>
<div class="line">email - <a class="reference" href="mailto:awoo&#64;archrock.com">awoo&#64;archrock.com</a></div>
<div class="line"><br /></div>
<div class="line"><br /></div>
<div class="line">Sukun Kim</div>
<div class="line">Samsung Electronics</div>
<div class="line">416 Maetan-3-dong, Yeongtong-Gu</div>
<div class="line">Suwon, Gyeonggi 443-742</div>
<div class="line">Korea, Republic of</div>
<div class="line"><br /></div>
<div class="line">phone - +82 10 3065 6836</div>
<div class="line">email - <a class="reference" href="mailto:sukun.kim&#64;samsung.com">sukun.kim&#64;samsung.com</a></div>
</div>
</div>
<div class="section">
<h1><a id="id5" name="id5">8. Citations</a></h1>
<table class="docutils footnote" frame="void" id="id6" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id2" name="id6">[1]</a></td><td>TEP 124: Link Estimation Extension Protocol</td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id7" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id3" name="id7">[2]</a></td><td>Philip Levis, Neil Patel, David Culler and Scott Shenker. &quot;A
Self-Regulating Algorithm for Code Maintenance and Propagation
in Wireless Sensor Networks.&quot; In Proceedings of the First USENIX
Conference on Networked Systems Design and Implementation (NSDI), 2004.</td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id8" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id1" name="id8">[3]</a></td><td>TEP 119: Collection.</td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id9" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id4" name="id9">[4]</a></td><td>Rodrigo Fonseca, Omprakash Gnawali, Kyle Jamieson, and Philip Levis.
&quot;Four Bit Wireless Link Estimation.&quot; In Proceedings of the Sixth Workshop
on Hot Topics in Networks (HotNets VI), November 2007.</td></tr>
</tbody>
</table>
</div>
</div>
</body>
</html>
